32-35: LGTM! Clear documentation improvement

The renamed method asJSONObject() better reflects its purpose, and the added documentation clearly explains its use case with ably-cocoa's publish operation.

42-42: LGTM! Test updated to match API changes

The test assertion has been correctly updated to use the renamed asJSONObject() method, maintaining test coverage while reflecting the API improvements.

27-27: LGTM! Consistent with API changes

The send method correctly uses the renamed asJSONObject() method, maintaining consistency with the API improvements.

Line range hint 3-5: Verify if @mainactor is the best solution

While @mainactor fixes the task isolation error, the TODO comment suggests this might be temporary. Consider investigating alternative solutions as part of issue #83.

1-145: Unit tests are comprehensive and validate all JSONValue cases

The test suite thoroughly covers the conversion between JSONValue and Ably Cocoa presence data, including end-to-end serialization and deserialization. This ensures reliability and correctness of the JSON handling.

3-3: Simplify PresenceData with Typealias

The PresenceData typealias has been updated to JSONValue, simplifying the representation of presence data throughout the codebase.

65-65: Adjust Initializer to Accept Optional PresenceData

The initializer for PresenceMember now accepts an optional PresenceData? for the data parameter. This allows for representing the absence of presence data with nil, distinguishing it from a JSONValue.null.

9-13: Update Method Signatures to Require Non-Optional PresenceData

The enter, update, and leave methods in the Presence protocol now require a non-optional PresenceData parameter. This enforces that presence data must be provided when these methods are called, enhancing data integrity.

Please verify that all calls to these methods in the codebase provide a non-optional PresenceData. Run the following script to identify any calls passing nil:

#!/bin/bash
# Description: Find calls to `enter`, `update`, and `leave` methods passing `nil` for the `data` parameter.

rg '\.(enter|update|leave)\(data:\s*nil\)' -t swift

#!/bin/bash
# Let's search for all calls to these methods to understand their usage patterns
rg '\.(enter|update|leave)\((data:)?[^)]' -t swift -A 1

#!/bin/bash
# Let's also check the protocol implementations to understand how these methods are used
ast-grep --pattern 'func $_(data: PresenceData) async throws'

#!/bin/bash
# Let's check if there are any overloads without the data parameter
ast-grep --pattern 'func $_(data: $_) async throws'

95-101: Refactor enter Method for Clarity

The enter method has been refactored to include two overloads:

• enter(data: PresenceData) which accepts presence data.
• enter() which calls enter(optionalData: nil) internally.

This separation enhances clarity and enforces explicit data handling.

Line range hint 104-116: Private Method enter(optionalData:) Handles Optional Data

The private method enter(optionalData:) consolidates the logic for entering presence with optional data. It constructs a PresenceDataDTO with userCustomData: data, ensuring consistent data handling.

129-136: Apply Consistent Refactoring to update Method

Similar to enter, the update method has been refactored with two overloads and a private update(optionalData:) method. This promotes consistency and clarity in presence data operations.

163-170: Implement Consistent Pattern for leave Method

The leave method now follows the same pattern as enter and update, with overloads and a private leave(optionalData:) method. This consistency improves maintainability.

233-246: Improve Error Handling in decodePresenceDataDTO Method

The decodePresenceDataDTO method now properly handles cases where ablyCocoaPresenceData is nil by throwing a descriptive error. This ensures that unexpected data formats are correctly managed.

1-34: Introduce PresenceDataDTO for Structured Presence Data

The new PresenceDataDTO struct provides a clear and structured way to handle presence data, encapsulating the userCustomData. It includes methods for initializing from a JSONValue and converting back to a JSON object, which enhances serialization and deserialization processes.

17-23: Ensure Robust Initialization from JSON Value

The initializer init(jsonValue:) checks that the provided jsonValue is an object and correctly extracts userCustomData. This validation prevents runtime errors due to incorrect data types.

25-33: Accurately Convert DTO to JSON Object Value

The toJSONObjectValue computed property efficiently constructs a JSON object from the PresenceDataDTO, including userCustomData only when it is not nil. This ensures that unnecessary keys are not included in the serialized data.

7-17: Validate Initialization from JSON Value with Comprehensive Test Cases

The initWithJSONValue test function covers multiple scenarios, ensuring that PresenceDataDTO initializes correctly from various JSON inputs, including cases with missing keys and null values.

19-23: Test Failure when Initializing with Non-Object JSON Value

The initWithJSONValue_failsIfNotObject test confirms that an error is thrown when attempting to initialize PresenceDataDTO with a non-object JSON value. This ensures robust error handling in the presence data deserialization process.

27-40: Ensure Correct Serialization in toJSONObject Tests

The toJSONObject test function verifies that PresenceDataDTO serializes to a JSON object accurately, covering scenarios where userCustomData is nil, a non-null value, or explicitly .null.

280-280: LGTM: Simplified presence data handling

The change to return nil for presence data in mock implementations aligns with the PR objectives to streamline the API.

Also applies to: 292-292

304-312: LGTM: Well-structured presence enter methods

The implementation provides a clean API with:

• Overloaded methods for flexibility
• Private shared implementation for DRY principle
• Thread-safety maintained within the actor

325-333: LGTM: Consistent update method implementation

The update methods follow the same pattern as enter methods, maintaining API consistency.

179-179: LGTM: Simplified presence method calls

The removal of explicit nil parameters makes the API more concise while maintaining the same functionality.

Also applies to: 191-191

205-205: LGTM: Simplified presence data handling in UI

The changes streamline presence data handling by:

• Using direct dictionary format for status
• Accessing data through type-safe accessors

Also applies to: 211-211

#!/bin/bash
# Verify consistent presence data access pattern across the codebase
rg -A 2 'objectValue\?\["status"\]'

#!/bin/bash
# Search for presence enter/update patterns to verify consistency
rg -A 2 'presence\.(enter|update).*data:'